-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduced placeholder support for headers tag attributes #6623
Conversation
I noticed that the previous Shouldn't the oder be other way round? If any changes to the |
Actually, let's just update 5.2. The reason is that we want clear alignment in what is supported in each released version as a whole. IOW, if we were to backport this to 5.1.x, etc., then we would update those accordingly. For this change, though, I believe we're just going to keep it to 5.2.x.
This will likely end up being more work than it's worth. We can perform that optimization later on down the road, if this causes performance issues. Also to your specific concern, I believe a check like this is run very early by the placeholder resolver itself.
Hmm, that doesn't sound quite right. What should happen is Spring Framework's
For some reason, those logs aren't pulling up right now. If you wouldn't mind removing your changes to the older |
Alright! I reverted the changes to the old
When I run the Let's see how the build looks like this time 🤞 |
Nice, @rhamedy! This looks great. Just one more thing, I think. Can you explain the whitespace diff in the I ask because, when I pull your branch onto my machine and run |
Added the functionality to allow the disabled and defaults-disabled attribute of <header> tag to accept a placeholder and resolve it during parsing. - Updated the spring-security .rnc files starting from 4.2 up to 5.2 with xsd:token type instead of boolean - Added unit tests for headers.disabled and headers.defaults-disabled attributes with placeholder - Modified the HeadersBeanDefinitionParser to support resolving placeholders - Updated spring.schemas to point to latest spring-security-5.2.xsd Fixes spring-projectsgh-6547
For some strange reason upon save in both I did come across a @jzheaux ^ |
Thanks, again, @rhamedy! This is now merged into |
Fixes gh-6547
Two points
Is it alright to update all the
.rnc
files starting from4.2
upto5.2
? The reason I did that is because in one of the test's xml, I changedspring-security.xsd
tospring-security-5.2.xsd
(or 5.2) and it failed with error message complaining about schema not matching and changing to4.2.xsd
did not fail. This was before the change theschema.handlers
.I am curious to whether I should include a check such as
if (element.getAttribute(attributeName).indexOf("${") !== -1)
in theresolveAttribute
ofHeadersBeanDefinitionParser
. It might be expensive to runresolve
even when it's not a property. I wonder if there are any edge cases with this if-check 🤔In order to succeed in running the unit tests locally, I had to setup a local
http
server and make it point to the changed versions of.xsd
files otherwiseEclipse
pulls straight from theurl
which obviously hasboolean
type instead oftoken
andxsd
validation fails.I was using a
web server
with a port (any port) that had:
in it's URL and I found out that spring does not:
in the URL ofxml
files and it converts it to=
which means it fails to load the rightNamespaceHandler
.